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INTRODUCTION 


ESA and NASA have a cooperation related to the demonstration of the value for space users of using dual GNSS 
system (GPS plus Galileo) receiver compared to use of a single GNSS system (GPS) receiver. For this demonstration a 
joint ESA-NASA activity has been initiated, based on the use of NASA’s SCAN Testbed on-board the International 
Space Station (ISS). The joint project has several objectives, e.g. generation of GPS and Galileo waveform, evaluation 
of signal performance, generation of PVT and also generation of a Precise Orbit Determination (POD). 

In this context, Qascom, has a contract with ESA for designing a Software Defined Radio Galileo/GPS Receiver for 
accurate positioning and timing that will be installed and experimented on the International Space Station (ISS) in the 
Space Communications and Navigation (SCaN) Testbed. The SCaN Testbed is an advanced and integrated 
communications system and laboratory facility that uses a new generation of Software Defined Radio (SDR) 
technologies that allows researchers to develop, test, and demonstrate new communications, networking, and navigation 
capabilities in space. 


The GARISS (GAlileo Receiver for the ISS) project is an element of the overall ESA-NASA cooperation, started in mid 
2016 and has as main objective the development of a Galileo and GPS multi-constellation waveform i.e. the 
combination of Software and Firmware components for processing the GNSS signals. 

The GARISS project is organized in three main phases: 


1. Design and Development of the Galileo/GPS waveform for the SCaN Testbed starting from existing Qascom 
GNSS SDR receiver. The design is limited to the implementation of the single frequency Galileo and GPS 
(LI/E1 or L5/E5a) receiver even if it has been assessed the feasibility of a dual frequency implementation 
(L1/E1 and L5/ES5a) in the same SDR platform. 

2. Qualification and test the Galileo/GPS waveform using “ground systems” available at the NASA Glenn 
Research Center (GRC). Experimenters can have access to two SCaN Testbed ground based systems for 
development and verification: the Experimenter Development System (EDS) that is intended to provide initial 
opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a 
high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final 
development testing and verification testing. 

3. Perform in-orbit validation and experimentation: this phase will consists on the collection of raw data in space, 
assessment on the quality of the measurements and receiver performances in terms of signal acquisition and 
tracking and finally the computation of positioning in space (Position, Velocity and Time) and assessment of 
its performance. 


This paper introduces the SCaN testbed architecture and provides a description of the mission with specific focus on the 
design and development trade-offs. The paper includes a high-level description of the waveform firmware and software 
architectures and some preliminary results showing the expected performance in space. IQ Samples collected by the 
SCaN Testbed and provided by NASA have also been processed to demonstrate the feasibility of the acquisition design. 
The paper concludes with an overview of the integration approaches describing the main technical challenges of this 
phase and the prototype boards that have been selected for the verification. 


THE SPACE COMMUNICATIONS AND NAVIGATION (SCAN) TESTBED ARCHITECTURE 
The SCaN Testbed includes of a Flight System and a Ground System, and for the experiments purposes makes use of 


space and ground data network assets, [1]. The SCaN Testbed payload is resident on ExPRESS Logistics Carrier 3 
(ELC3) on an exterior truss of the International Space Station (ISS) and has been launched and installed in 2012. The 


testbed consists of reconfigurable and reprogrammable Software Defined Radio (SDR) transceivers/transponders 
operating at S-band, Ka-band, and L-band, along with the required RF/antenna systems necessary for communications. 
As in the world of communication, software-defined radio (SDR) technology is interesting because it provides the 
opportunity to develop a platform that is adaptable to unforeseen space mission needs. NASA has deployed the SCaN 
Testbed to verify how SDR technology including SW design, development, verification and operation processes that 
can be adopted in future mission, [3]. 

The SCaN test Bed include three SDRs: Harris SDR, General Dynamics (GD) SDR and the Jet Propulsion Laboratory 
(JPL) SDR. The SDRs have S-band duplex Radio Frequency (RF) links directly with the ground, also referred to as the 
Near Earth Network (NEN), S-band duplex RF links with the Tracking and Data Relay Satellite System (TDRSS), also 
referred to as the Space Network (SN), Ka-Band duplex with TDRSS, and L-Band receive-only link for the Global 
Navigation Satellite signals. The architecture diagram is shown in Figure 1. 
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Figure 1 SCaN Testbed High Level Architecture 


Each of the Software Defined Radios has an Operating Environment (OE), which includes an operating system and 
provides infrastructure services to applications and waveforms in accordance with the Space Telecommunications 
Radio System Standard (STRS). 

The SDR used in for the GARISS experimentation is the JPL SDR, for a detailed description see [3]. The elements of 
the JPL SDR used for the scopes of the project include the following elements: 

e GNSS Antenna: the GNSS signals are received through a Dorne & Margolin DMC146-6-1 passive antenna 
with a choke ring, [4]. 

e Front End: the front is designed to directly sub-harmonically samples the filtered GPS L-band signals at L1 
(1575.42 MHz), L2 (1227.6 MHz), and L5 (1176.45 MHz) The GNSS signals are filtered against interference, 
amplified, split, and fed into three channels: L1, L2, and LS. In each of these channels the front end performs 
the analog to digital conversion at a clock rate of 38.656 MHz, [5]. 

e SDR Platform: the platform includes 

o two FPGAs:Xilinx Virtex II with accompanying volatile and non-volatile memory resources 
o abaseband SPARC processor, supporting an RTEMS operating system 


STRS DEVELOPMENT FRAMEWORK 


The Galileo waveform will be developed on the STRS framework. The STRS was initiated by NASA to define a 
standard architecture for space-qualified radios in support of future NASA missions, [7]. 

The STRS architecture separates the STRS operating environment (OE) from the waveform applications. The OE 
middleware abstracts the SDR hardware from the waveform application software. Moreover it manages the functions 
within the SDR, such as: command and telemetry, inter-process communications among software elements, control 
functions such as loading and unloading the waveform from memory and execution of the waveform. 

User applications access the RTOS (Real Time Operating System) of the operating environment through a POSIX 
(Portable Operating System Interface for Unix) interface and the waveform access remaining OE functions through a 
set of APIs (Application Programming Interfaces) defined by the STRS architecture (STRS APIs). Once a user 
waveform application is loaded on a platform, the POSIX and STRS APIs provide the software interfaces to the 
underlying hardware. On the firmware interfaces within the FPGA, the STRS standard calls out requirements for FPGA 
signal abstractions between the application and the platform hardware provided by the platform. 

The radio functions are distributed among different modules that according to the STRS nomenclature are: 


e Signal Processing Module (SPM): this module represents the FPGA and it is intended to implement signal 
processing functions. The SPM will implement the high rate waveform application components 

e General-purpose Processing Module (GPM): this module represents the microcontroller and it is intended to 
execute the low rate signal processing waveform component and the managing SW. 


The STRS Standard allows the developers to prepare waveform software and firmware that is modular, portable, 
reconfigurable, and reusable. 


GALILEO WAVEFORM DESIGN 


The GARISS Waveform design include the following two main components: 

e Waveform Software (WSW);: this is the software dedicated to GNSS signal processing, navigation solution 
and interface with the Ground (Telemetry and Telecommand) that will run on the SPARC processor. As shown 
in the basic scheme of the Software architecture in Figure 2 the WSF is organized in the following four 
modules: 

o Receiver Manager (RM): in charge of managing the communication with the Ground Interface 
including the processing of the configuration files and the preparation of the Telemetry Data. 
Moreover it configures and monitor all the other SW modules. 

o Signal Processing Manager (SPM): that controls the acquisition and tracking channels and manages 
the communication with FPGA to collect correlation values and to control the NCOs 

o Navigation Messages Manager (NMM): that is responsible for the collection, decoding and 
interpretation of related fields of the received navigation messages. 

o Navigation Manager (NM): that performs the computation of the raw measurements (Pseudorange 
and Carrier Phase) and the PVT. The module includes also satellite visibility prediction functions to 
support the Warm Start Acquisition. 


e Waveform Firmware (WFW): this is the firmware, dedicated to GNSS signal processing that will run on one 
of two of the XLININX FPGAs. The functionalities allocated to the FPGA are: 
o Clock Management 
Parallel Correlation for Acquisition (one channel) 
Serial correlation for Tracking (up to six channels for Galileo and six channels for GPS) 
Carrier and Code Phase Integrators 
Spreading Code Generator 
Numeric Controlled Oscillator (NCO) 
Noise Floor estimation 


000000 


In addition, the following external SW will be developed Ground Monitoring and Control SW (GMCSSW): this is a 
SW engine operated on ground in charge to collect all the data from the Waveform (Telemetry) and prepare the 
Waveform configuration including aiding data. 
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Figure 2 Waveform High Level Architecture 


The Waveform Software (WSW) state model has the state machine, shown in Figure 3 that includes the following 


states: 


START: the module is initialized with empty structures. In this state the WSW waits the configuration provided 
by the ground interface. 

CONFIGURE: the WSW is configured using the configuration received from ground. 

RUN: the WSW is running in nominal conditions. 

ERROR: when an error occurs in START, CONFIGURE or RUN states the WSW switches to this state. In this 
state, the WSW tries to solve the error otherwise it switches to the SHUTDOWN or hardware reset. 
SHUTDOWN: the WSW is switched off in the correct mode. The receiver manager stops the threads, it 
removes the configuration and it deallocates the memory. 

HARDWARE RESET: the receiver is switched off. This procedure is performed calling a specific API of the 
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Figure 3 Software High Level State Machine 


The waveform has two different Interfaces with the ground segment: 

e Configuration Interface: the configuration interface is used to configure the processing of each module of the 
waveform and to upload aiding data for signal acquisition. The aiding data that will be sent are the Ephemeris 
for GPS satellite and Galileo satellites, the GGTO Data and the SCaN Test Bed orbital data defined Two Line 
Element (TLE) format. Timing information is provided by via STRS API. 

e Telemetry Interface: the waveform output data are sent to ground segment using the Telemetry interface. The 
packets contains tracking, navigation message and PVT data. Different levels of granularity are supported. A 
binary protocol is used and a maximum of 150 MB of data per day is expected to be produced. 


One of the most critical aspects of the Waveform design is the Signal Acquisition: the Doppler search window is very 
wide (+35 KHz) and GNSS satellites are in view to the GNSS L Band antenna only for few minutes. Therefore, during 
operations, the selected baseline acquisition mode is the Warm Start. This has been implemented in an innovative way 
for a space receiver as the availability of the Ground to SCaN Test Bed communication link allows to transmit to the 
Waveform aiding data (satellites ephemerides, and SCaN Testbed TLE). Moreover, the waveform can retrieve the GPS 
time from the ISS through the Avionics subsystem. Aiding data also used to generate the PVT, in the first version of the 
waveform, without extracting the navigation information from the Signal In Space. 


PERFORMANCE TRADEOFFS 


In parallel to Waveform design Qascom is also performing an extensive assessment of which are the achievable GNSS 
processing performance in space. As part of this activity, simulated and real data collected on the SCaN Test bed have 
been used. These results are also supporting the feasibility of dual frequency (L1 and L5) waveform implementation. 
Dual Frequency is highly beneficial in particular for Precise Orbit Determination (POD) experimentations. The first part 
of the assessment is based on the processing of the dual constellation (GPS and Galileo) scenario data, generated by 
means of a GSS6700 Spirent Simulator. These measurements, as seen by the L band Scan Testbed antenna, have been 
used as input for Satellite Visibility and PVT availability analyses and for the estimation of the range of Doppler and 
Doppler rate variations. The following main assumptions have been used in the analysis configuration: 


e GPS Constellation Status in mid-2017: 
o 31 Satellites transmitting LICA signal 
o = 12 Satellites (IF block) transmitting L5 signal 
e Galileo Constellation Status in mid-2017: 
o 16 Satellites transmitting El signal 
o 15 Satellites transmitting E5a signal 
e SCaN testbed L band antenna field of view is above 30 degrees, [6] 
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Figure 4 L Band Antenna Field of View 


The following parameters have been considered for the satellite visibility and PVT availability analysis. 


e Average Time of Satellite Visibility: that is the average period of time in which a satellite is in visibility of the 
L Band Antenna with an elevation higher than 30 degrees 


e Mean Number of Visible Satellites: that is the average number of satellites that are in visibility of the L Band 
Antenna 


e PVT Availability: represent the percentage of time over the experiment duration in which the PVT can be 
computed (i.e. at least 4 satellites are in view) 


e Average Time for Four Satellites: represents the average time in which there are at least four satellites in view 
that can be used to compute the PVT. 


The Table 1 summarize the visibility and PVT availability results for each single signal: 


GPSLICA | GalileoE1 | GPSLS5 | Galileo ESa 
Average Visibility Time 20.29 min | 20.07 min 


Average Number Of 
Visible Satellites a08 Be ae 


PVT Availability 92.5 % 12.41 % 0.37 % 11.34 % 


Average Time Four 


Satellites 28.35 min 4.47 min 54.1 sec 4.67 min 


Table 1 GPS and Galileo Visibility and PVT Availability Analyses 


This analysis has shown that there are on average more satellites in L1/E1 than L5/E5a (as expected) and therefore 
during the experimentation phase it is more “probable” to compute a PVT using L1/E1 than L5/ES5a. In addition, for the 
Waveform single frequency implementation a dual constellation (GPS and Galileo) is mandatory in L5/ESa case for 
generating a PVT considering the low availability of GPS and Galileo only L5/ES5a signals. 
In summary: 

e PVT Availability is 99.7 % for L1/E1 and 64.8% for L5/E5a 

e the Average Time for Four Satellites is 6 hours for L1/E1 and 12 minutes for L5/E5a 


As already stated, one of most critical part of the signal processing is the Signal Acquisition. To support the definition 
of the Waveform acquisition engine (algorithms, thresholds and acquisition modes) the following analyses have been 
carried out: 


e Analysis of the Doppler and Doppler Rate of the satellites in view to the L Band Scan Test Bed antenna. These 
values has been used, for example, to define the width of the acquisition search space. 

e Link Budget versus Elevation taking into account the L Band Antenna Pattern, the Antenna Noise Temperature 
and the LNA noise figures provided by NASA. These results has been used to tune the acquisition thresholds 
in Cold and Warm start modes. 


The following Table 2 reports the results of the analyses for the four signals. In Figure 5 it is shown the profile of the 
Doppler and Doppler rate of Galileo E1 signals for a simulation of 300 minutes. Figure 6 reports the CNO profile for 
Galileo E1 and Galileo E5a: the green area represent the field of view of the L band antenna. As expected the CNO is 
quite high above 30 degrees elevation, allowing short acquisition times even in Cold Start. 


GPSLica | Galileo E1 GPSL5__| Galileo B5a 


36.05KHz 33.39 KHz 26.92 KHz 25.26 KHz 
Doppler Max / Min 


-35.90 KHz 33.84 KHz -26.78 KHz -25.53 KHz 


-19.92 Hz/s -20.93 Hz/s -14.93 Hz/s -15.89 Hz/s 
Doppler Rate Max / Min 

-65.98 Hz/s -60.40 Hz/s -49.28 Hz/s on 63 Hz/s 
CNO (30 deg) 45 dBHz 44 dBHz 46 dBHz | 46dBHz dBHz 


Table 2 Doppler and Link Budget Analyses 


Doppler Galileo Doppler Rate Galileo 


Doppler [KHz] 
Doppler Rate [Hz/s] 


150 150 
Time [min] Time [min] 


Galileo E1 Doppler Galileo E1 Doppler Rate 


Figure 5 Doppler and Doppler Rate profile for Galileo E1 
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Figure 6 C/NO versus Elevation for Galileo L1 Galileo E5a 


Finally, real IQ data collected (in 2013) on the SCaN testbed have been used in order to validate the acquisition 
processing of the Waveform. The following Table 3 reports the results of Galileo and GPS signal acquisition in L1/E1 
and LS/E5a. A detailed view of Galileo E1 signal acquisition for PRN 19 is shown in Figure 7. This specific satellite 
has been acquired with C/NO: 50.03 dBHz, Code Phase: 5.996171e-03s and Doppler: +5560.9 Hz. 
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Table 3 First Signal Acquisitions in L1/E1 and L5/E5a using ScaN Test Bed IQ samples 
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Figure 7 Galileo E1 (PRN 19) Signal Acquisition 


VALIDATION AND EXPERIMENTATION APPROACHES 
The following three test Phases are foreseen for the GARISS project: 


e Unit Level Testing: this type of tests will be executed for each of the two component of the Waveform (WSW 
and WFW). The Testing will be executed at Qascom premises using selected boards that are representative of 
the JPL SDR hardware. 

e System Level Testing: this testing phase will be executed at NASA premises. The objective is the verification 
of the integrated waveform components. Two integrated systems are available: the Experiment Development 
System (EDS) and the Ground Integration Unit (GIU) as defined in the experimenter Handbook, [3] 

e Experimentation: this activity consists in the in-orbit validation and experimentation of the Waveform. 


One of the major challenges of the GARISS project is due to the fact that a prototype of the JPL SDR platform is not 
available in Europe (at Qascom or ESA premises). In addition, at unit level it will not be possible to test the “closed 
loop” and the interactions between the SW and the FW. Therefore, some strategies have been proposed to overcome 
this limitation. The following test architecture is proposed for the WFW verification: 
e §©Virtex II Pro Development Board including a Xilinx XC2VP30 FPGA where the Waveform Firmware is 
loaded 
e Cypress EZ-USB FX3, or other device: this is a super speed peripheral controller that will be used to stream, 
via USB the samples from the PC to the FPGA development board. 
e ISS IQ Scenario File: this is an IQ file containing signals generated by Spirent constellation simulator. The 
files will dump the RF output of the constellation simulator in a realistic ISS scenario. 


To test the main functionalities, such as the correlation, the selected approach consist in using a simple scenarios with 
satellite with known and constant Doppler and code phase that allow to set a static configuration avoiding run time 
interaction between SW and FW. 


The following test architecture is proposed for the Software verification: 

e Semi Analytic Signal Generator: this will be used to replace the FPGA in the generation of the correlation 
values. It will be connected to the beagle bone board, where the waveform SW is running, through a serial link. 

e DSP Board: this will be used in replacement of the AT697 Microcontroller and will be used to run the 
Waveform SW. It will provide to the Semi Analytic Signal Generator feedbacks such as the Doppler and Code 
Rate. Alternatively, the SW verification will be done in simulation mode. 

e SV Range/Doppler/Power, Motion and Navigation Message Scenario File: these files are output of the Spirent 
constellation simulator and will be used to generate a realistic scenario in terms of dynamics with the Semi 
analytic simulator 


This architecture will allow verifying the main engines running in the SW and the acquisition and tracking channels 
state machines. The semi analytic signal generator allows generating signal dynamics starting from the Spirent 
Scenario. 

The System Level Testing phase and the Experimentation are foreseen in 2017. 


CONCLUSIONS 


The GARISS project has the objective to develop and experiment a multi-constellation Galileo and GPS receiver for the 
ISS SCaN test bed, in the JPL SDR platform. The paper provides a high level overview of the project tasks and the key 
elements of the Software and Firmware design. The receiver will implement, in its first versions, a Warm Start 
acquisition mode exploiting the aiding data that can be provided form ground. A preliminary assessment of the expected 
range of Doppler and Doppler rate, Link budget and satellite visibility have been provided. The acquisition has been 
demonstrated using real data captured on the ISS SCaN test bed. The project that currently is in the development phase 
will allow to experiment the first Galileo signal processing on the ISS. 


REFERENCES 


[1] https://spaceflightsystems.grc.nasa. gov/sopo/scsmo/scan-testbed/ 

[2] D. Chelmins, B. Welch, "COMPARING ON-ORBIT AND GROUND PERFORMANCE FOR AN S-BAND 
SOFTWARE-DEFINED RADIO", IAC-14-B2.8-YPVF.3.10 

[3] NASA SCaN Experimenters Handbook, GRC-CONN-PLAN-5006 Rev A, 6/18/12 

[4] C. B. Duncan, D. E. Robison, C.L. Koelewyn, “Software Defined GPS Receiver for International Space Station”, 
ION NTM 2011 

[5] http://www.techbriefs.com/component/content/article/ntb/tech-briefs/electronics-and-computers/13029 NASA 
Tech Briefs, Connect Global Positioning System RF Module 

[6] SCaN Testbed Flight and Ground System Description, GRC-CONN-DOC-5022 Rev A, 04/26/2012 


[7] Space Telecommunications Radio System (STRS) Architecture Standard Release 1.02.1, NASA/TM—2010 
216809/REV1 March 2012 


